Add support for separate encodings for stdin, stdout, and stderr#1284
Add support for separate encodings for stdin, stdout, and stderr#1284gnodet merged 2 commits intojline:masterfrom
Conversation
- Add new methods to Terminal interface: stdinEncoding(), stdoutEncoding(), stderrEncoding() - Update TerminalBuilder to support separate encodings - Add support for standard Java system properties: stdin.encoding, stdout.encoding, stderr.encoding - Add unit tests to verify encoding functionality Fixes jline#1282
| Charset encoding, | ||
| Charset stdinEncoding, | ||
| Charset stdoutEncoding, | ||
| Charset stderrEncoding, |
There was a problem hiding this comment.
@gnodet, thanks so much for the lightening fast fix. 💯
Judging from the JavaDoc, I'm struggling to understand the relation between encoding and std{in,out,err}Encoding parameters:
- What is actually meant by "general character encoding to use"? I mean, if it won't be used for
std{in,out,err}, what will it be used for? - Is
encodinga fallback forstd{in,out,err}Encoding? If so, what happens when both are provided? - Which of the
encodingandstd{in,out,err}Encodingvariables are nullable?
I'd appreciate it if you can help with the above questions.
There was a problem hiding this comment.
@gnodet, thanks so much for the lightening fast fix. 💯
Judging from the JavaDoc, I'm struggling to understand the relation between
encodingandstd{in,out,err}Encodingparameters:
- What is actually meant by "general character encoding to use"? I mean, if it won't be used for
std{in,out,err}, what will it be used for?- Is
encodinga fallback forstd{in,out,err}Encoding? If so, what happens when both are provided?- Which of the
encodingandstd{in,out,err}Encodingvariables are nullable?I'd appreciate it if you can help with the above questions.
When building the actual terminal, you should end up with the following:
this.encoding = encoding != null ? encoding : Charset.defaultCharset();
this.stdinEncoding = stdinEncoding != null ? stdinEncoding : this.encoding;
this.stdoutEncoding = stdoutEncoding != null ? stdoutEncoding : this.encoding;
this.stderrEncoding = stderrEncoding != null ? stderrEncoding : this.encoding;
So all are nullable, and encoding is a fallback.
However, the detection is done in the TerminalBuilder. For stdin, the computation is:
- use
stdinEncodingfield if specified - else use
org.jline.terminal.stdin.encodingsystem property if specified - else use
stdin.encodingsystem property if specified - else use the computed general encoding
The general encoding is computed as follows:
- use
encodingfield if specified - else use
org.jline.terminal.encodingsystem property if specified - else use
codepagefield to compute the encoding if specified - else use
org.jline.terminal.codepagesystem property to compute the encoding if specified - else use UTF-8
So the general encoding, stdin, stdout and stderr, as computed above, are given to the TerminalProvider to actually build the terminal.
There was a problem hiding this comment.
Thanks so much for the elaborate response. 🙇
I have a few more questions, if I may:
- Can
encodingbe used for anything else thanstd{in,out,err}encoding? If not, would it be possible to deprecate/remove it completely? - Shouldn't
MouseSupport::readExt(Terminal)useterminal.stdinEncoding()instead? - Shouldn't
AnsiConsole::ansiStream(boolean)useterminal.std{out,err}Encoding()instead?
Fixes #1282